Network security system and method

ABSTRACT

In a security system for network communications with client devices, each client device has a communication module for communicating with at least one server over a network, a data storage module for storing one or more covert data values of one or more operational events at the client device, and a covert identifier generating module which creates at least one covert identifier based on the stored covert data values. The covert identifier is provided in one or more network messages to the server, or otherwise sent to the service provider, and may be provided in response to a specific request received over the network, or routinely in one or more messages normally involved in network communications. The server compares covert identifiers received from client devices having the same client identifier in order to detect possible clones.

RELATED APPLICATION

The present application claims the benefit of co-pending U.S.provisional patent application No. 60/760,475 filed Jan. 20, 2006, whichis incorporated herein by reference in its entirety.

BACKGROUND

1. Field of the Invention

The present invention relates to network communications between a serverand client device, and is particularly concerned with a network securitysystem and method for detecting clones of true or properly registeredclient devices attempting to steal services without payment or otherwisemimic a real client device.

2. Related Art

In a distributed computing environment, pirates attempt to stealservices by creating multiple clients with credentials identical to avalid client or authorized subscriber, thereby allowing non-payingsubscribers to share (steal) the services of a paying authorizedsubscriber. Since the credentials appear valid, the server sendsbroadcast keys or the like to such clones, enabling non-authorizedsubscribers to view broadcasts, engage in two-way communications, or thelike. Such cloning techniques are a significant problem to networkproviders. Pirates also attempt to duplicate or clone client devicessuch as smart cards which are used by authorized individuals as creditor automated teller machine (ATM) cards, in mobile phones, for highsecurity identification and access-control cards, public transportcards, and other purposes. Cloning of smart cards also causessignificant problems to providers of such services as well as theauthorized card users.

Therefore, what is needed is a system and method that reduces orovercomes these significant problems found in the conventional systemsas described above.

SUMMARY

Embodiments described herein provide for the addition of covert securitydata to normal messages between a client device and server, so that aserver can determine if more than one client device communicating withthe network has the same registered credentials or client identifier(client ID), indicating the presence of one or more cloned clientdevices.

According to one aspect, a security method for detecting cloned clientdevices is provided, which comprises receiving a message from a clientdevice at a server, the message containing a covert identifier derivedfrom one or more operational events at the client device, determiningwhether the covert identifier matches a covert identifier for the clientdevice stored at the server, and reporting detection of a cloned clientdevice if the covert identifiers do not match.

The covert identifier stored at the server may be based on one or morecovert data items generated by the server or by the client device, orboth, and may have been received in a previous message which purports tobe from the same client device. If the messages originate with differentclient devices, such as a real client device and a cloned client device,the covert identifiers do not match, since the timing and values ofoperational events at one client device are not identical to those atanother client device. The covert identifier may be a value generated byor based upon one or more operational events, for example the time ofoccurrence of an event or the number of times a particular event hasoccurred at the client device, or may be a transformed version of one ormore covert data values using a hashing function or the like.

The client device may be any type of computing device capable ofreceiving and/or sending data over a network, such as set top boxes(STBs), personal computers, game consoles, cellular phones, personaldigital assistants (PDAs), video equipment, smart cards, and the like.The covert identifier generated for the client device may comprise oneor more covert data values collected and stored by a client device, or atransformed version of such covert data values, and may be based on anyoperational characteristic or event of a client device which changesover time and which can be stored by the client device, or by the clientdevice and server. The covert identifier may be a token or valueprovided by the server, or may be a combination of client and servergenerated covert data values. An operational characteristic of a clientdevice as referenced herein is an event which occurs at or in connectionwith the client device and which is unique to that particular clientdevice, such as a time at which a predetermined operational eventoccurs, for example sending or receiving a predetermined message at theclient device or server, a firmware update, a delay time between sendinga message to the network and receiving a response from the network, thetime when the nth network packet is received at the client device, thenumber of times a certain operational event occurs, a token sent to theclient device from the server, a count of Entitlement Control Message(ECM) packets received, a channel the client device was tuned to at apredetermined time, number of channel changes in a predetermined time, aregister value contained on a chip in a client device, and so on. In thecase of a smart card, the operational characteristic used to generatecovert data may be a time of first use of the smart card, themicrosecond time when the smartcard was used for a certain operation,the total number of data bytes processed by the smartcard at a certaintime or captured at a certain event such as a broadcasted event trigger,or any other operational data, count, or event occurring during the useof the smartcard, for example. In the case of a mobile phone, call logsat the phone may be used to generate the covert identifier, byprocessing the call log with a hashing function to generate anidentifier which is unique to that phone. The operational characteristicis one which is created by operation of a particular client device andis therefore not easily hacked or duplicated by a cloned client device,for example the microsecond time of day that an event occurred or atrigger occurred, or new data was captured. Covert identifiers may beupdated periodically using new operational events to provide the covertdata values, to further reduce the risk of successful hacking.

Some examples of possible covert data values which may be used to createa covert identifier unique to a client device are the last time aparticular type of message was sent from or received by the clientdevice, the number of times a particular event has occurred, such asnumber of items purchased, number of transient key updates received,number of times a certain type of data message or network packet wasreceived, or number of times a client device has performed a certainevent, the internet protocol (IP) address used by the Dynamic HostConfiguration Protocol (DHCP) server when used in the system, valuesobtained from other network devices such as cable modem or signalstrength, value of a client data parameter after a predetermined numberof events has occurred, and the like. A covert data value may comprisedata received in a message from the server and used in a subsequentmessage to the server. This value may be updated by the server at eachsubsequent communication. In this way, the server recognizes that thereis a potential clone device if a message is received which does notcontain the updated covert data value, i.e. there is more than oneclient device with the same credentials on the system. More than onecovert data value may be used for the covert identifier in each messagefor added security. In the case of a smart card, the covert identifiermay be based on the time the card was used, the number of itemspurchased, or the like.

Event triggers may be used in some embodiments to update or modifycovert data values or start a count or timer which results in updatedcovert data values used to generate a new covert identifier, or modifiesthe messaging protocol or data contained in a message between a clientand server.

In another aspect, a security system for detecting cloned client devicesis provided, which comprises a network server data storage module whichstores a plurality of sets of client credentials or client identifiers(ID) for a plurality of authorized or real client devices and alsostores covert identifiers based on operational characteristics of aclient device which are received in messages from client devices, and acovert data processing module which compares a covert identifier in amessage received from a client device with a previously stored covertidentifier corresponding to the same client ID and which creates a clonedetection report if the covert data identifiers do not match.

If the network is a two-way network, covert identifiers based oncollected operational events are exchanged during normal networkcommunications. If the network normally operates as a one-way networkbut has a return channel for certain client communications,predetermined covert data values based on usage of the device arecollected and used to create covert identifiers stored by clientdevices. The covert identifiers are sent to the server in messages viathe return channel when available, for example during a periodic renewalprocess. The server stores the first covert identifier for a certainsubscriber. If a covert identifier is later received which purports tooriginate with the same client device, a clone detection report isissued by the server.

According to another aspect, a client device is provided which includesa covert data generating module for generating a covert identifier basedon data generated by operation of the client device, and a covert datastorage module for storing the covert identifier. If the client deviceis intended for use in a two way network environment, or in a one waynetwork environment including a return channel for certaincommunications, the client device may also include a message generatingmodule for generating messages containing the currently stored covertidentifier. The covert identifier is subsequently sent to a networkserver over a network in a covert data field embedded in a message, oras a data value in response to a request from the server or anycombination thereof The message may be a type of message normally sentin two-way communications to a network, or in a message as part of aperiodic renewal procedure or other standard message if the clientdevice is normally involved only in one way communications with anetwork.

Where there is no return channel for a one way network service, theclient device creates and stores a client identifier which may beupdated periodically based on new events at the client device. Theclient device or a network server may include a service code generatingmodule which generates a service code message at a client device atpredetermined intervals. This message may ask subscribers to call aservice center or send a short message service (SMS) text message via amobile phone or internet connection to the service center, providing thesubscriber identification and the currently stored covert identifier inthe client device. Since the currently stored covert identifier isdifferent for a real client device and a cloned client device, becausethey were operated differently, the service center can determine whentwo messages have been received with the same client or subscriberidentification but with different covert identifiers. The service centercan then take additional steps to determine which client device isassociated with the authorized subscriber, and renews only that clientdevice, cutting off service to any other client device using the samesubscriber or client identification.

The covert identifier is generated by operational events occurringduring actual operation of a client device. Because the operationalevents occur after manufacturing the client device and are based on howthe subscribers use the client devices, the operational events areunique to a particular client device. These operational events aredifferent even between cloned client devices, because cloned clientdevices do things differently after they are powered-on, and it is thedifference in operation that is used to generate the covert identifier.The covert data therefore provides a unique identifier for a particularclient device which is stored by the client device and subsequently usedin messages to a server. Where the client device is normally used onlyin one way network communications, the unique covert identifier can beprovided to the network in a periodic renewal procedure, or may berequested by a network server if cloning is suspected.

The covert data generating module may be incorporated in a centralprocessing unit of the client device, which maybe embodied in a singlechip (system on a chip or SOC) in some cases, such as in a smart card,cellular phone, or the like. The covert data storage module may also beincorporated in the central processing unit (CPU) or a separate database associated with the central processing unit, or memory internal orexternal to the CPU.

A client device message format in one embodiment comprises a messageidentifier field, a covert data field, and at least one additional datafield containing the message to be communicated to the server, such as aclient identification field or key request, or as part of a message ormessage ID. The message type may be a logon message, a broadcast keyrequest message, an e-commerce purchase message, a request to changechannels, a subscription renewal message, or the like. If the messagetype is a logon message, the additional data fields contain the username and password. The covert data field contains a covert identifierwhich may comprise one or more covert data values or items or atransformed version of such covert data values. The covert identifiercan be used by the server on receipt of the message to determine whethermore than one client device is using the same credentials. More than onemessage type may contain a covert identifier.

In one embodiment, the current covert identifier is sent to a serverfrom a client device as part of normal messages such as logging onto asystem, requesting a decryption key, performing an e-commercetransaction, or other messages and events that occur normally within asystem. Covert data values used to create the covert identifier may bebased on various events, and event triggers may be used to define eventswhich trigger the updating or modification of a previously stored covertidentifier. Covert identifiers added into the normal messaging between aclient and server do not require added messages or addedacknowledgements between the client and server, reducing the likelihoodthat a hacker can monitor the protocol and determine how to hack asystem. As such, a hacker who is attempting to steal services by cloningsubscriber credentials, for example, of a set top box (STB), also needsto have knowledge of the meaning of the covert identifier and thetriggers that cause a change in the covert identifier to assure thatauthentic STBs and cloned STBs have the same covert identifier. Morethan one covert data value may be used to create covert identifiers, forexample a client library of two or more covert data values may be usedto create covert identifiers in each selected client message to aserver. The client library of covert data values is periodicallyupdated, making it more difficult to conceal cloned devices from aserver. In alternative embodiments, the covert identifier can also besent with separate messages between the client and server.

The security system may also include a renewal process designed toidentify suspected clone devices. The renewal process may be initiatedin response to a clone detection report generated by a network server,or may be carried out at periodic intervals or when clones are suspectedfor other reasons. The renewal process is designed to re-authorize onlya single client device when several such devices are using the samecredentials.

Other features and advantages of the present invention will become morereadily apparent to those of ordinary skill in the art after reviewingthe following detailed description and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The details of the present invention, both as to its structure andoperation, may be gleaned in part by study of the accompanying drawings,in which like reference numerals refer to like parts, and in which:

FIG. 1 is a block diagram illustrating a network with a real orauthorized client device and some cloned client devices communicatingwith a server in one embodiment of a security system for detectingpotential cloned client devices;

FIG. 2A is a diagram illustrating data fields in a prior art user logonmessage;

FIG. 2B is a diagram illustrating data fields in one embodiment of auser message containing a covert identifier used at the server in oneembodiment of a system for detecting potential cloned client devices;

FIG. 3 is a block diagram illustrating a client device configured toinsert a covert identifier in messages according to one embodiment;

FIG. 4 is a flow diagram illustrating one embodiment of a method ofdetecting a cloned client device;

FIGS. 5A and 5B are flow diagrams illustrating one embodiment of theclone detecting method;

FIGS. 6A to 6F illustrate messages generated at various stages in themethod of FIGS. 5A and 5B;

FIG. 7 is a flow diagram illustrating an embodiment of a method forinserting covert identifiers in messages between a client device and aserver;

FIG. 8 is a flow diagram illustrating one embodiment of a servicerenewal method using covert identifiers; and

FIG. 9 is a flow diagram illustrating a modification of the method ofFIG. 8 for use in a one way network environment having no return channelfrom a client device.

DETAILED DESCRIPTION

Certain embodiments as disclosed herein provide for detection of morethan one client device using identical credentials. For example, onemethod and system as disclosed herein allows for detection of potentialclone devices using a covert identifier based on values of operationalevents specific to a client device which is added into the normalmessaging between a client device and a server.

After reading this description it will become apparent to one skilled inthe art how to implement the invention in various alternativeembodiments and alternative applications. However, although variousembodiments of the present invention are described herein, it isunderstood that these embodiments are presented by way of example only,and not limitation. As such, this detailed description of variousalternative embodiments should not be construed to limit the scope orbreadth of the present invention as set forth in the appended claims.

In the following description, a client device may be any type of devicecapable of computing and receiving data from a network, such as a settop box (STB), personal computer, game console, cellular phone, personaldigital assistant (PDA), personal media player, video equipment such asa digital video receiver (DVR), digital video disc (DVD) player (DVD),compact disc (CD) player, smart card, or the like. An authentic or realclient device is the device which is properly registered with the serverfor receiving services over a network, or local services such asbanking, purchases, and the like authorized by a network, as in the caseof a smart card. A cloned client device is a device which has identicalcredentials to a real client device properly registered for service onthe network, and which is used by an unauthorized or non-paying user inan attempt to obtain money or services without authorization. The terms“covert data”, “covert data value” and “covert data item” are used toindicate unique data values based on operational characteristics of aclient device, e.g. values created by operation of a particular clientdevice or communication of that device with a server, or on tokens orvalues based on operation of a client device which are created by theserver and embedded in messages to the client device. Such values arecovert because their nature makes them difficult for hackers to detectand duplicate in cloned client devices, and because the data isgenerated after manufacturing. The term “covert identifier” indicates anidentifier unique to a specific client device which is generated basedon covert data values associated with operation of that device, and maycomprise one or more actual covert data values in some embodiments, ormay be a transformed version of such data values using a hash functionor seeding a random number value or performing some other transform onthe data. The term “event trigger” is used to indicate events thattrigger the updating or modification of the covert identifier containedin a messaging protocol between a client device and server. An “eventcounter” counts events performed by a client device, and may be used asan event trigger when the number of counted events exceeds a threshold.

FIG. 1 is a block diagram of a network security system incorporatingclone detection according to one embodiment in which a server 10communicates with a real or authorized client device 12 over a network14, and a number of cloned client devices 15, 16 using identical clientcredentials also send messages to the server 10 over network 14. One,two or more clone devices may attempt to use network services at any onetime by posing as client device 12. Computing environment pirates oftenattempt to steal network and other services by creating multiple clientswith identical credentials, thereby allowing non-paying subscribers toshare or misappropriate the services of a paying authorized subscriber.

As illustrated in FIG. 1, the server 10 is linked to server data base(DB) 20 which has a data storage module 23 for storing covertidentifiers which may be received from client devices in messages and/orgenerated by the server. As noted above, each covert identifier is basedon operational events at a specific client device. Server 10 has acommunication module 11 which controls network communications and aclone detection module 13 which compares covert identifiers in messagesreceived from client devices with previously stored covert identifiersin module 21, as described in more detail below. Server 10 hasadditional standard server processing and control modules which are notillustrated.

In the system of FIG. 1, client device 12 sends a message M1 to theserver 10, while clone devices 15, 16 send similar messages M2 and M3 tothe server. These messages may be sent in any sequence, and the serveris adapted to detect the presence of one or more potential clonesregardless of the order of transmission of messages M1 to M3. Eachmessage is adapted to include a covert identifier 18 embedded in apredetermined covert data field or portion of the message. Covertidentifiers for client devices communicating with the server areassociated with the client credentials for a client device and stored incovert data storage module 23 for comparison with future covertidentifiers received from one or more client devices having the samecredentials, as described in more detail below. Each true and clonedclient device has a data base or memory storage (RAM, ROM, FLASH,EEPROM) or register storage 30, 32, 34, respectively, in which thecovert data values are stored and updated at the predetermined eventtriggers. Although the data base is shown separate from the clientdevice in FIG. 1, it may be housed in the client device or may be partof a central processing unit or system on a chip (SOC) in the clientdevice, or device memory such as RAM memory, Flash memory, SecureMemory, and the like.

A client device (real or cloned) 12, 15, or 16 is illustrated in moredetail in FIG. 3. The client device may be any client device configuredfor communication over a network, such as a set top box, personalcomputer, game console, mobile phone, PDA, portable media player, DVDplayer, DVR, or a smart card, or the like. The client device has anassociated data storage module 30, 32, 34 which is shown separately butmay be incorporated in the same housing as other modules of the clientdevice, or on the same chip as the other modules in some cases. Theclient device also has a communication module 17 for controlling networkcommunications with server 10, a covert identifier generating module 19for creating covert identifiers based on covert data values, eventtriggers or data received from the server, and a message formattingmodule 28. Client devices also include standard client device processingand control modules which are not illustrated in FIG. 3. The datastorage module has a covert data table module 29 for storing the currentset of covert data values, as described below. Where the covertidentifier is a transformed version of the covert data values, thecurrent covert identifier or matrix of covert data values or group ofcovert data values is also stored in module 29.

In one embodiment, message formatting module 28 is adapted to insert orembed the current covert identifier in one or more types of message sentto the server. In another embodiment in which the client device is usedonly to receive one way network communications and does not have accessto a return channel to the network, message formatting module 28 iseliminated and the covert identifier generating module is configured todisplay the currently stored covert identifier in the form of a uniqueidentification code to the user of the client device in connection witha periodic subscriber renewal process, as described in more detail belowin connection with FIG. 9.

In one embodiment, the covert security data or identifier 18 is based onoperational characteristics of the device from which the message istransmitted. Such characteristics are difficult or impossible toduplicate in a clone of the client device, since cloned client devicesare not operated identically to authentic or real client devices andoperational events such as messages, updates, and the like occur atdifferent times in different devices. Obtaining micro-second identicalevents in real world client devices is nearly impossible. An operationalcharacteristic of a client device is a value unique to that specificclient device which is generated based on operation of the clientdevice, such as a time at which a predetermined operational eventoccurs, for example sending or receiving a predetermined message at theclient device or server, a firmware update, a delay time between sendinga message to the network and receiving a response at the network, timewhen the nth network packet is received at the client device, the numberof times a client device performs a certain operational event in aselected time period, a token sent to the client device from the server,a count of ECM packets received, a channel the client device was tunedto at a predetermined time, number of channel changes in a predeterminedtime, a register value contained on a chip in a client device at acertain time, and so on. It turns out that there are an unlimited numberof operational data values that can be used to generated covert datavalues (or data values unique to the operation of a client) because theexact data value is not important but what is important is that thelikelihood of the data value being different based on the operation oftwo identical devices is great. If two or more client devices using thesame credentials are communicating over the network, such operationalcharacteristics are not identical from one client device to the other,and are uniquely created by operation of a particular client device by auser. Such operational characteristics and the covert identifiers basedon such characteristics therefore cannot be easily hacked or duplicatedby a cloned client device. Operators of cloned client devices areunlikely to be able to obtain such characteristics of the true orauthentic client device, and would not normally even be aware of whichspecific operational characteristics are used to create the covertidentifier, and in one embodiment the covert data values change betweendifferent versions of the client software.

The server extracts the covert identifier received in a message from adevice having certain credentials, and compares this identifier withthose received in previous messages apparently from the same device. Ifthere is no match, it is likely that one or more clones are being used,and the server can provide appropriate notification of likely clonedetection to the system operator for further action. Since the servercannot determine which of several client devices with identicalcredentials sending messages are cloned devices, the requested serviceis provided to the devices, in addition to the clone detectionnotification to the operator.

In one embodiment, a covert identifier is transmitted in ordinarymessages exchanged between the client and server. For example, assumethat the client needs to log onto a system and a logon message isdefined. The standard logon message includes a user name and password.In one embodiment, the logon message includes a covert identifier 18 inaddition to the user name and password. When the client device attemptsto logon to a system, the client device provides standard logoninformation such as user name and password and the covert identifier isembedded in the logon message (or any message or all messages) forming alogon command that includes the covert identifier as part of thestandard logon message. The logon message contains the user name,password, and additional bytes of data containing the covert identifier.In one embodiment, the data items or values contained in the covertidentifier or used to generate the covert identifier change at differenttimes based on operating events within the client, or change based ontime of day, or based on a time period elapsing after a certain event,so that the covert identifier can be updated either by changing covertdata values at a particular time or by adding new covert data items toprevious covert data items in essence increasing the number of covertdata items for a particular client.

Any standard message exchange between a client device and server may beused for detecting clones, such as an initial logon message. A covertidentifier can be combined with normal messages and/or events such aswhen a client logs into a system. In addition to information typicallyfound in a logon such as the client user name and password, the covertidentifier can be added to the logon message which is specific tooperation of a certain client device, such as the last time the userlogged into the network or the time difference between the current logonand the prior logon. Covert data can be applied to all messages in acommunication system or only selected messages, such as the logonmessage or other types of messages.

FIG. 2A illustrates a conventional log on message protocol as currentlyused. This message includes a message identifier field (ID) 21 whichdefines the message type from a group of messages supported on thesystem and which is typically unique for each message in a system. Itmay also include an optional sequence number field 22 which contains aunique number for each message of any type in the system, and istypically an incremental count that allows the system to eliminatemessage replay attacks by verifying the sequence number is new beforeprocessing the message. When the message is an initial logon message, italso has a user name field 24 which contains the user name for a user orclient device on the system registered for the service or associatedwith a subscriber account with the service provider, and a passwordfield 25 which contains the password for the user associated with anaccount or service. The password is provided when the user or subscriberfirst subscribes or registers with the system or service provider, andis verified by the server in subsequent requests for service by theuser. Services can be accessed or the user can purchase items using theservice only after the password is correctly provided in passwordprotected systems. In addition, covert data can be used as part ofpassword salting for each client with the server side being aware of thecovert data used to salt the password or data, or the server sidedownloading the encryption key or salting key into the client. Suchpasswords are sometimes obtained by hackers and used in conjunction withclone devices in attempting to obtain services without payment.

FIG. 2B illustrates an embodiment of a modified initial logon messagewhich contains a covert identifier in covert data field 18 in theregular log on message structure. The ID field, sequence number field22, user name 24, and password 25 are identical to the correspondingfields of FIG. 2A, but the message is modified to provide a covertidentifier in a data field 18 between the fields 22 and 24. The covertdata field 18 may be provided at other locations in the message in otherembodiments, and may be provided in different types of messages such asrequest broadcast key messages, e-commerce purchase messages, changechannel messages, and the like. The covert identifier may be provided inonly one specific type of message between a device and server, or may beprovided in each message sent by the device, or intermittently invarious messages. Intermittent transmission of covert identifiers maymake such identifiers harder to track by potential hackers. Becauseencrypted messaging is always more secure than unencrypted messagingbetween client and server, in one embodiment covert data is transmittedover an encrypted connection such as Internet Protocol Security (IPSec),or secure socket layer (SSL) or other form of encryption between clientand server.

As illustrated in FIG. 1, each of the messages M1, M2 and M3 has acovert identifier in field 18, but the covert identifiers in messages M2and M3 do not normally match that of message M1. This is because thecovert identifiers in one embodiment are based on covert data valuesgenerated by operational characteristics or operational events of theclient device, such as time of sending or receiving certain messages atthe client device or server, number of times a certain type of datamessage or network package was received, and the like. The covertidentifier may comprise different operationally generated covert datavalues contained in different regions of the covert data field, or maycomprise a transformed version of such covert data values. Such valuesare extremely unlikely to be identical in cloned client devices to thecovert data values at a real client device, since the operation ofcloned client device does not normally match the operation of a clientdevice or another cloned client device. For example, a first segment ofthe covert data field may contain the first power on time of a clientdevice in microseconds. After a certain time period or number of events,a second segment of the covert data field may add a subsequent power ontime for the device to the first power on time (e.g. T1, T2). Eventhough the server does not know whether the second power on time wasadded by the client device or a cloned client device, the original poweron time T1 is extremely unlikely to be identical for both devices, andthe second and subsequent covert data items added to the covert dataexchanged between client and server are designed to be unique betweenclients, and because additional covert data items are generated duringthe continued operation of the client the likelihood of the covert databeing identical is very low.

The server receives messages from authentic and/or cloned client devicesand saves the most recent covert identifiers associated with clientcredentials of the authorized user in server covert data storage module23. When a subsequent message is received which is apparently from adevice associated with the same client credentials, the server comparesthe covert identifier with the previously stored covert identifier forthat client. If no match is found in one or more of the covertidentifiers, one of the devices communicating with the server is likelyto be a clone device, and the server reports to an operator that a clonehas been detected. The operator can then initiate procedures todetermine which device is a valid or authorized client device and whichdevice is a clone.

FIG. 4 is a flow diagram illustrating one embodiment of a method ofusing the system of FIGS. 1, 2B and 3 for detecting the presence ofcloned client devices on a network. In step 40, a client device sends amessage to the server containing a covert identifier in covert datafield 18. The message may be of the format illustrated in FIG. 2B, forexample, or may be any other type of standard network communicationmessage with a covert identifier comprising one or more covert datavalues inserted at a selected data field in the message, or anidentifier which is a transformed version of one or more covert datavalues. The server receives the message and extracts the covertidentifier from the message (42), and then compares the covertidentifier with the stored covert identifier corresponding to the clientcredentials associated with the registered client device from which themessage appears to originate (step 44). The server determines whetherthere is a match (step 45) based on the comparison, i.e. determineswhether there is a match between any part of a stored covert identifierand the covert identifier in the message. If a match is found, theserver sends a message reply when appropriate to the client device (step48), stores the new covert identifier, and the desired service ortransaction takes place. If a match is not found, i.e. there is no matchbetween any part of the covert identifiers, the server generates areport to the operator indicating that a potential clone has beendetected (step 46), and an optional flag may be set in memory. If thecovert identifier is a multiple digit code created by transforming coverdata values, a match means that a received covert identifier isidentical to a stored covert identifier. If the covert identifier is oneor more covert data values based on ongoing events, the received covertidentifier may match only part of the previously stored covertidentifier, while it includes new covert data values added after thelast message to the server. A match is still found if part of thereceived covert identifier matches the stored covert identifier, but amatch is not found if there is no match in any part of the covertidentifier.

The server may continue communications with the device which sent themessage when a potential clone is detected, since it has not yet beendetermined whether or not that device is a cloned client device, i.e.the server does not have sufficient information to determine which oftwo client devices communicating with the server is a clone. In a laststep, service may be discontinued to a device which is found to be aclone, or to all devices, leaving the authorized subscriber to contactthe service provider to arrange for their service to be continued.

In one embodiment, covert data values on which the cover identifier isbased may be generated by certain operational events at a client device.Some examples of possible covert data values generated by operationalevents are:

-   a) Number of times a client has performed a certain event such as    requesting a key or initializing a session with a server, or    performing an e-commerce transaction.-   b) The number of prior items purchased by a subscriber.-   c) The number of transient key updates received by a client.-   d) The time of the last firmware update-   e) The time of the last key request for the client-   f) The time of the last message of a particular type, or the count    of the number of times a certain message was received, or the delay    between the current message and the prior message being received    from the server.-   g) The time when a certain type of message was received by the    client-   h) The time when a certain type of message was received from the    client-   i) A count of the number of times a certain type of data message or    network packets was received with examples including video ECM    (Entitlement Control Messages), count of different MPEG2 PID values,    count of packets on a particular TCP IP port number, etc.-   j) The time delay between a request message being sent to the    network and the response being received back from the server.-   k) The last time a multicast join was performed, or the value of the    last multicast join.-   l) The IP address provided by the Dynamic Host Configuration    Protocol (DHCP) server when DHCP is used in the system.-   m) The time remaining on a DHCP lease when DHCP is used in the    system.-   n) Values obtained from other network devices such as the ranging    parameters for a cable modem or the signal strength of the network    after 3 days of running a new client.-   o) Data changing or a new message being generated after a certain    period of times, for example the client device receiving a covert    data value from the server that indicates to the client device in    how many minutes the client device should contact the server.-   p) The value of a client data parameter after a number of events    such as the TV channel number when 57 channel changes occurred.-   q) A new covert data value derived from a previously used covert    data value processed with a function that creates the new covert    data value.-   r) A covert data value generated from data within a chip on the    client device, or covert data value generated from processed or    scaled data from a chip or hardware plug-in board or card or secure    memory in the client device.-   s) A covert data value such as a token or key received from the    server that the client device retains and uses as part of a covert    identifier containing one or more covert data values or items in    subsequent messages with the server. Covert data received from the    server can be transformed by the client device and the transformed    version can be returned to the server as a covert identifier in    subsequent messages. This allows the server to pass tokens or keys    to the client in normal messages between the client and server as    part of normal system message. The server supplied token used for    client covert identifier can be sent in a separate message but the    preferred message is to pass the covert data value from the server    in a normal message.-   t) Time of day when 12000th network packet was received.

Some of the above listed values may additionally or alternatively beused as event triggers or event counters which trigger the updating ormodification of covert identifiers contained in a messaging protocolbetween a client device and a server. For example, an operational eventmay trigger a counter which counts subsequent operational events, suchas the number of channel changes at a client device, for example, andrecords a covert data value when the user has changed channels apredetermined number of times. The covert data value may be the time ofday when the predetermined count is reached, or the time it took beforethe predetermined count was reached. Other types of operational eventsmay be counted in the same way to provide an event trigger, such asnumber of messages of a certain type sent or received by a clientdevice, number of items purchased, or the like, or the number of eventsitself may be used directly as covert data values. Other possible eventtriggers may be the time when an operational event occurs, such as afirmware update. Such event triggers may be used to change a previousset of covert data values to a new set of covert data values based ondifferent operational events, with the new covert data values then usedto create the covert identifier. This makes it much more difficult forhackers to determine which particular operational events are used togenerate the covert identifier.

Covert data 18 may be built in a table. One embodiment of a possiblecovert data table is shown in Table 1 below. In the table shown belowthe covert data table is built using two covert data items or values.One covert data item is the time of day (TOD) when the latest broadcastkey request (BKEY) message was made and the other is the number oftransient key updates obtained by a client device such as a set top box(STB) or other client device. Other covert data items based onoperational characteristics may be used in alternative embodiments, andmore than two covert data items may be used for added security.Initially both values in Table 1 are 0, and the initial covertidentifier may be 0, 0. Table 1 below is only an example of two datavalues that can be together in one version of a client software release.It is envisioned that other covert data values may be used to create acovert identifier and that different data values may be used betweendifferent software versions. For example, in this example the number oftransient key updates is being used, but in another version of thesoftware the time of day (TOD) of the last transient key update could beused, or the number of seconds between the first and second transientkey updates could be used.

TABLE 1 Covert Data Table Covert Data Description TOD of first Time OfDay that the first or nth Broadcast Key BKEY request (BKEY) request wasmade by client device. Initially this is set to 0. Number of The numberof times that the client device had its Transient Key transient keyupdated. Initially this is set to 0. Updates

FIGS. 5A and 5B illustrate a flow diagram of the method steps in oneexample of an embodiment for detecting clone devices using covert dataas in Table 1 above. Table 2 below illustrates one possible example ofcovert data values stored at both the server and client device or clonedclient device at various steps in FIGS. 5A and 5B, and FIGS. 6A to 6Fillustrate messages generated at various stages in the example of FIGS.5A and 5B. In Table 2 and FIG. 5, the term “real client device” is usedto designate the original or authentic client device associated withclient device credentials registered at the server, while the term“cloned client device” designates a client device which is an exact copyof the real client device with the same credentials. In step 100 of FIG.5A, a real or authentic client device is installed and registered asassociated with a subscriber to the services provided by server 10,which saves the credentials of the subscriber client device in data base20. At the first power on of the client device 14 (step 101), the covertidentifier is initialized (step 102) to a known starting value at boththe server data base and client device data base. The covert identifierin this case comprises a set of covert data values as indicated in Table2 below. In this example, at least one of the covert data values used inthe covert identifier is time of day (TOD) at which a broadcast key(BKEY) request was made by the client device, although any other covertdata values may be used in place of the BKEY request TOD or in additionto the TOD in other embodiments.

The initial covert data values as stored in the server data base 20before any BKEY request has been received are Acknowledged (Acked)TOD=0, Not Acknowledged (NotAcked) TOD=0, i.e. covert data or identifierfor this client at the server is 0, 0, while the initial covert datavalue stored at the client device when it first powers on is TOD=0.Since this is the first power application after the client device wasinstalled, the TOD event trigger for the broadcast key request is zero,because the client device has not yet requested broadcast keys. Any orall covert data can be set at an initial state such as zero on the firstpower up of a client device and/or at the server prior to receipt of afirst message from a client device. In alternative embodiments, one ormore non-zero covert data values may be generated during theregistration process when a subscriber's client device is registered atthe server, and used to create an initial covert identifier, or includedin a covert identifier in addition to one or more covert data valueswhich are initially set to zero.

In Table 2, the not acknowledged (NotAcked) value of a covert data itemstored at the server is the last value issued to a client device (realor cloned) by a server which has not yet been acknowledged in a messagefrom the client device. The NotAcked value is moved to the acknowledged(Acked) column of the value stored at the server when the client returnsthe NotAcked value or a value derived by the client device from theNotAcked value. The client may return the NotAcked value in the nextmessage to the server in one embodiment, as illustrated in Table 2 andFIGS. 5 and 6. In an alternative embodiment (not illustrated), theclient device sends a specific acknowledgement message to the server onreceipt of the new NotAcked value, confirming that the NotAcked valuehas been successfully stored in the client device data base. At thispoint, the NotAcked value replaces the Acked value at the server.However, this alternative is more susceptible to hackers obtaining thecovert data value. The method illustrated in FIGS. 5A and 5B, in whichthe only acknowledgement of the NotAcked value occurs when the nextmessage of a designated type is sent to the server, is more covert.

After initializing, the client device 14 sends a request for broadcastkeys (BKEY request) to the server in step 104. In one embodiment, thisrequest contains a covert identifier or covert security data 18. Thecovert identifier in the BKEY message in this case is as follows:

-   -   TOD Last BKEY request=0    -   Transient key updates=0.

In other words, the covert identifier in the BKEY request is 0, 0, andthe format of this message M1 is illustrated in FIG. 6A.

The server receives the BKEY request (step 105), and extracts the covertdata values in the covert identifier from the request, then checks thesevalues against the corresponding values stored at the server. Thiscomparison is described below for the BKEY TOD covert data value only ina series of messages, but a similar comparison is carried out for othercovert data values in a covert identifier, such as a value based ontransient key updates. Since this is the first message from any clientdevice using these client credentials, the BKEY TOD data matches (step108), and the server returns the BKEYs to the client device (step 110)with a TOD value T1 determined by the server, i.e. the time of day ofreceipt at the server of the first BKEY request from this client. Oneembodiment of the format of the BKEY reply message R1 is illustrated inFIG. 6B, in which the new TOD value T1 is provided in a message fieldafter the message ID and SN. In an alternative embodiment, the TOD valuefor the message may be read by the client device locally, instead ofbeing received in the message from the server. The TOD value receivedfrom the server may be replaced with any type of data value or tokensent from the server in other alternative embodiments.

In the example provided in Table 2 below, the TOD value T1 is 8437, andis added to the server data base as a NotAcked TOD in step 114 since noacknowledgement of receipt of this value has yet been received from theclient device. As noted above, the client device may be programmed tosend an acknowledgement of receipt of the TOD value T1 in an alternativeembodiment, but in this embodiment no such acknowledgement is sent untilthe next BKEY message, so the TOD value T1 remains a NotAcked valueuntil and unless it is acknowledged in a subsequent BKEY message, whichis a more covert option. At this point, the TOD values in the clientidentifier saved at the server are Acked TOD=0, NotAcked TOD=T1 or 8437in this example.

TABLE 2 Example of covert data values at various steps in FIG. 5 Covertdata values Client/Clone Step Server Actions Server DB in client DeviceActions 101, The initial covert data values for a AckedTOD = 0 TOD = 0All covert data at 102 client device are initialed to a NotAcked aninitial state known starting value. TOD = 0 (0, 0) 112, Server returnsBKEYs with a AckedTOD = 0 114 Time Of Day (TOD) value NotAckeddetermined by the server. Server TOD = 8437. adds latest covert datavalue(s) to Note 8437 is a new the server DB as unacknowledged TODsupplied by value(s). DB contains last known the server to the goodvalue (0 in this example) client. plus last unacknowledged value(current TOD = 8437) 115, TOD now equals Real client device 116 8437.saves TOD of last BKEY passed from server in BKEY delivery message innon- volatile memory 122 AckedTOD = 0 TOD = 0 Cloned client NotAckeddevice covert data TOD = 8437 in BKEY Request is as follows: TOD LastBKEY request = 0, Transient key updates = 0 126, Server returns BKEYswith a new AckedTOD = 0 130 Time Of Day (TOD) value NotAcked determinedby the server. Server TOD = 9902. adds latest covert data value(s) toNote 9902 is a new the server DB as unacknowledged TOD supplied byvalue(s). DB contains last known the server to the good value (0 in thisexample) client, eliminating plus last unacknowledged value thenon-Acked (current TOD) value of 8437 sent to the other STB requestingkeys before the cloned STB 132 TOD in clone is Cloned client 9902.device saves TOD received from server in BKEY delivery message. 134ACKed TOD = 0, TOD in Real client Real client sends notAcked TOD = 9902device is 8437 renew BKEY message to server with Acked TOD of last BKEYrequest = 8437, and Transient Key Updates = 0 135 Server receives BKEYrequest ACKed TOD = 0, Acked TOD = 8437 and checks TOD in DB againstnotAcked TOD = 9902 TOD in request. 140, Server updates notAcked TOD toACKed TOD = 0 TOD in real client 142 11305 and sends BKEYs and notAckeddevice is 11305 TOD to STB TOD = 11305

In step 115, the real client device receives the broadcast keys in thereply from the server, along with the new TOD value T1 (in this example8437). The client device then stores the new TOD value (step 116), anddecrypts encrypted data such as broadcast data from the server using thebroadcast keys (step 118). In the illustrated example, a cloned clientdevice powers up (120) sometime after the first broadcast keys arereceived by the real client device and before the real client devicesends a subsequent broadcast key request to the server. This sequence ofevents does not happen in all cases, and is only one possible example ofa sequence of real and cloned client device communications with theserver. The cloned client device sends a broadcast key request to theserver (122) containing a covert identifier comprising initial covertdata values 0, 0, and a possible format of this message M2 isillustrated in FIG. 6C. The first message from any cloned client devicein this embodiment contains the same covert identifier as the firstmessage from the authentic or real client device, i.e. 0, 0. If thismessage is received by the server before the real client device hasacknowledged a new TOD value from the server, the server still has noway of knowing that there is a cloned client device. If it is receivedafter a new TOD value has been acknowledged by the same client devicewhich initially requested BKEYs, the server knows that there are twoclient devices on the system using identical credentials, and generatesa clone detection report as in FIG. 4.

In the example of FIGS. 5A and 5B, a cloned client device sends thefirst BKEY request to the server before the real client device hasacknowledged receipt of a new TOD value from the server. On receipt ofthe BKEY request, the server extracts the covert data values 0, 0 andcompares these values with the covert data values stored for the realclient device having the same credentials (step 124). At this point, acovert data match is found (step 125), i.e. the received covert data iscorrect, since no specific acknowledgement of receipt of the Not AckedTOD T1 (e.g. 8437) has yet been received from the client device. In thisparticular example, the server does not know if the message containingthe TOD was never received by the client device for some reason, such asnetwork failure or the client device being turned off, and thereforedoes not assume that there is any cloned device present. The server database contains the last known good value of the TOD (in this case 0) plusthe last unacknowledged TOD value T1. Since the acknowledged value is amatch, the server sends the broadcast keys to the cloned client devicewith a new TOD value T2 (step 126) in a reply message which may have theformat illustrated in FIG. 6D in one embodiment. In the particularexample provided in Table 2 above, the value T2 is 9902. At the sametime, the NotAcked TOD at the server is changed to T2 (or 9902 in thisexample) in step 30, as illustrated in FIG. 5B, eliminating thepreviously stored NotAcked TOD T1 (or 8437 in the example of Table 2).

The cloned client receives the BKEY message and new TOD value T2 in themessage from the server and saves the new TOD value T2 (step 132), andproceeds to decrypt data such as broadcast data received from the server(step 133). In the example illustrated in FIG. 5B, the nextcommunication with the server after step 132 is a message sent from thereal client device requesting broadcast keys (BKEY Request) since thereal client device needs to renew its BKEYS (step 134). This message mayhave the format illustrated in FIG. 6E and contains a covert identifiercomprising the covert data values currently stored at the real clientdevice, specifically the TOD of the last BKEY request from this clientdevice (T1 or 8437) and the transient key update number (0 in thisexample). In step 135, the server receives the new BKEY message from thereal client device and compares the current stored Acked and NotAckedTOD values (specifically 0 and T2 or 9902) with the TOD value T1 or 8437received in the covert identifier from the client device. Since thevalue T1 received from the client device is not equal to either theAcked value 0 stored at the server, or the NotAcked value T2 stored atthe server (step 136), the server reports clone detection to the systemoperator for further action (step 138). Other server side processing canbe applied at this point to detect clones. The server does not denyservice since it cannot determine which of the two client devicessending messages is the real or authentic client device, and thereforesends BKEYs and a new TOD value T3 (11305 in the example of Table 2above) to the real client device (step 140) in a reply message which mayhave the format illustrated in FIG. 6F. The server then stores the newTOD value T3 as a NotAcked value in the server data base (step 142), andthe real client device also stores the new TOD T3.

The method of FIGS. 5A and 5B illustrates one possible method andsequence of events in which a cloned client device sends a message to aserver after the real client device has received its first BKEYs fromthe server but before the real client device requests renewed BKEYs fromthe server. Such events may occur in different sequences depending onusage of true and cloned client devices, and more than two clientdevices with the same credentials may send messages to a server duringthe same time period. Cloned client devices may send messages to theserver at any time and in any order relative to similar messages sentfrom a real client device. Regardless of the order, the server candetermine the presence of a cloned client device because the covert datavalues in messages from either the real client device or one or morecloned client devices do not match one or more currently stored valuesat the server. For example, referring to FIG. 5A and step 122 of Table2, if the real client device sends a subsequent BKEY request to theserver at this stage, before any message is sent by a cloned clientdevice, then the covert data values in the BKEY request are T1, 0 or8437, 0 in the specific example of Table 2. The server receiving thismessage notes the match between the TOD value from the client device andthe notAcked TOD saved in its data base, and changes the Acked TOD from0 to T1. A new notAcked TOD T2 is then sent in the reply to the clientdevice. A cloned client device subsequently communicating with theserver sends a TOD=0, since it is the first communication from thatdevice to the server. This TOD does not match either the Acked TOD (T1)or the Not Acked TOD (T2) stored at the server, and a clone detectionreport is generated by the server. A similar failure to match occurs atsome point in any message sequence when more than one client deviceusing the same credentials is communicating with a server, regardless ofthe order of communications between a server and a real client deviceand cloned client devices.

In the embodiment of FIGS. 5 and 6, and the specific example of thisembodiment outlined in Table 2 above, the covert identifier in eachmessage comprises two or more covert data values. However, the covertidentifier may comprise a code generated based on such covert datavalues, for example by transforming the values using a hash function orthe like. The message containing the covert identifier is a broadcastkey request in the above embodiment, and the client device receives abroadcast from the server. The client device in this case is a mediaplayer such as a television set top box, personal computer, or any otherclient device capable of playing a broadcast such as televisionbroadcast. The server may be one that distributes broadcast televisionchannel decryption keys to clients. However, other types of clientdevice and service providers can use the same covert data techniques indifferent types of messages. As noted above, covert data techniques ofthe above embodiments can be applied to any type of network serviceprovider and to any type of client device linked to servers of theservice provider, such as personal computers, cellular phones, personaldigital assistants (PDAs), video equipment (TIVO, DVD, CD, etc.), andany other type of client device, and for any type of service such ason-line banking, e-commerce, data logging, message communicationssystems, etc. In the above embodiment, broadcast television channeldecryption keys (BKEYS) are the keys necessary to decrypt encryptedbroadcast TV channels as is typically used for premium televisionschannels such as Home Box Office (HBO) or the Movie Channel. Premiumtelevision channels are optional channels that a cable TV or internetprotocol (IP) TV subscriber may elect to purchase. The techniquesdescribed herein are also applicable to any encryption techniques wherekeys are distributed to client devices to allow access to various typesof network services, or can be used in different types of messagesbetween a server and a client device in addition to, or instead of,decryption key request messages.

Because there is the possibility that a real client device does notreceive a message from a server due to network failure or due to theclient device being turned off before the message response is received,the embodiment of FIGS. 5A and 5B may include server side processing toreduce the number of false clone detection alerts generated, whereby aclone detection alert is an indication that a client has been detectedwith client credentials identical to another client. In one alternativeembodiment, as mentioned above, an explicate client acknowledgement issent from the client device each time a covert data item used in acovert identifier is updated, and the server coordinates the expectedcovert data item in the server database based on the acknowledgementfrom the client that a server supplied covert data item was successfullyreceived and stored by the client. The use of a direct acknowledgementmessage between the client and server indicating that a covert datatoken from the server has been stored by the client, or that the clientcovert data item has been acknowledged by the server can improve thedetection of clones but creates additional messages that are processedby the server and can be intercepted by hackers.

In one embodiment, the server sends unique covert data items or tokensto a client device for use in subsequent messages. Examples of dataitems or values that the server may send to the client device includetemporary data values periodically changed by the server when the clientand server communicate, temporary keys sent from client to server, andthe like. In one embodiment, the server sends temporary or transientencryption/decryption keys to a client and the transient keys becomespart of the key ring used in encrypting messages between the client andserver. The use of transient keys prevents cloned clients fromcommunicating with the server because only one client contains theappropriate keys to achieve encrypted communications between a clientand a server. The transient keys may be sent over a session baseencrypted communications channel such as provided by SSL or provided byDiffie Hellman type key exchanges so network packets containing theupdated transient keys supplied by the server cannot be decrypted bycloned devices obtaining the same transient key update messages. Suchsession based encryption may be used for any type of communications. Inone embodiment, the server sends a token or tokens to the client device,which are stored by the client device and used in subsequentclient-to-server messages. The server may provide a unique token atrandom times or at fixed intervals to a client device.

In the example of Table 2, two covert data values are shown. However,one, two or more covert data values may used with values that areuniquely provided by the server and/or values that are uniquelydetermined by the client based on operation of the client device. In oneembodiment, covert data module 29 at the client device may includenon-volatile memory, and parts or all of the covert data may be storedlocally in the non-volatile memory (hard disk, Flash memory, or thelike) on the client device. The power-on order of real and cloned clientdevices or the order in which they connect to a network, or the orderthey make a first connection with the server, is not important and thetechniques described above do not require the client devices to power upin any order. Thus, the first client device to power up in FIGS. 5A and5B may be a cloned client device rather than a real client device, andreal and cloned client devices may communicate with the server in anyorder and at any times. Regardless of the message order, this embodimentenables the server to determine when there is more than one clientdevice using the same client credentials when a message is received inwhich the covert data value does not match a covert data value at theserver, indicating that a real client device has been cloned.

FIGS. 5A and 5B illustrates covert clone detection using a single covertdata item being sent from the server to a client device in the form ofthe Time of Day (TOD) of the last request from a client device. In analternative embodiment, one or more covert triggers may be used. Acovert trigger is a trigger that takes place after a number of eventsoccur and which responds by modifying the covert data used to create thecovert identifier, or providing a new piece of covert data that can betracked by the server. There are numerous possible covert triggers inthe normal operation of a client device, and covert triggers or eventscan be based on multiple categories of events such as time (total numberof hours client device has been active, random number of hours afterclient device was installed or updated, or the like), messages (totalnumber of video entitlement control messages or ECMs received, totalchannel changes), or internal data processing (e.g. TOD when the100,000th video packet was decrypted). Other examples of a coverttrigger include a trigger that occurs when a client device such as a settop box (STB) has switched channels 100 or 200 times, for example, or atrigger that occurs when a certain number of client events occur and thetrigger saves the client time of day (or other parameter) when thetrigger occurs. Another example is the actual value of the 15000th ECMpacket received, or the Time Of Day (TOD) when the 15000^(th) ECM packetwas received or a hash of the two data values. Events which triggercreation of a covert data value occur at different rates in two clientdevices with identical credentials (authentic/real and cloned clientdevices), so that the authentic or real client device and cloned clientdevices have different covert data and therefore different covertidentifiers. The covert identifiers are used on the server side todetect multiple clients running on a network.

In one embodiment, client libraries of saved covert values areperiodically changed to save new or different covert data values whichin turn are used to generate a covert identifier. In this way, hackerswho may have obtained one client library do not know when a new eventwhich creates a covert data value used in a covert identifier mightoccur after a client library has been updated. Hackers need to take allthe cloned client devices off the network to avoid detection after aclient library software update, in order to try to determine what coverttriggers are programmed into the client library, when the triggersoccur, and what covert data is stored in the client library in responseto a trigger. Such updates may be generated by a server and may usesecure processing capabilities contained within the client device. Theclient firmware download method for updating the client library may useddigitally signed code images to allow the client to authenticate thedownload. The head-end software may have application programminginterface (API) functions or a data carousel interface for downloadingclient software.

In one embodiment, covert identifiers contain data that may be staticfor a number of requests and then the covert data used to generate thecovert identifier changes based on a covert trigger, or the covertidentifier for every message of a certain type changes, such as the Timeof Day or TOD for the prior message request. Covert data used in acovert identifier can originate within the client device, or be sentfrom the server as part of the messaging, or may be a combination ofclient/server data. The covert identifier can include data that isprocessed by the client or server such as applying current covert datavalues to a mathematical transform or cryptographic hash.

In one embodiment, covert data values used in a covert identifier mayalso change based on the server responding to a request in one of anumber of different ways. In one example, the first 10 broadcast keyrequests receive one value of covert data and subsequent requests beyond10 receive a different response in which the covert data is changed orscrambled or both. Changes can occur on client or server side or both.The covert identifier is contained in a message blob or field as part ofa normal message processed during normal system processing and themessage blob may vary between two different code releases of the clientsoftware. In addition, the message blob may have meaningless random dataapplied as a data whitener. In one embodiment, the data blob has threeto five covert data values and the covert data values change based ondifferent events or triggers occurring at different times.

In the embodiment described above in connection with FIGS. 5 and 6, acovert identifier based on time of day of a message is provided inbroadcast key request messages or the like. Table 3 below illustrates anexample of a transformed covert identifier created in client devicescomprising mobile phones.

TABLE 3 Mobile phone covert identifiers Real Phone Clone 1 Clone 2Mobile ID (ESN) 100-4452 100-4452 100-4452 Call log # TOD Dur. # TODDur. # TOD Dur. N1 8:22 1:06 N3 23:45 7:45 N5 16:41 3:16 N2 9:11 0:23 N4 1:02 3:36 N6 21:42 10:44 Covert 391740 457492 112208 identifier

In Table 3, one phone is real and the other two are clones, and eachphone creates a covert identifier based on the operation of the phone.In the example above only the first two call entries are used togenerate a unique covert identifier (ID). The call log of each phone isprocessed with a cryptographic hashing type function that generates aunique covert ID for each phone, resulting in an identifier that isunique to each phone even for perfectly cloned phones. Because thephones were cloned at manufacturing and each phone is used slightlydifferently over time, the covert identifiers are extremely difficult toduplicate, even if the owners of the phones tried to create identicalcall logs to generate identical covert identifiers. This is because itwould be necessary to obtain micro-second identical events in order tocreate perfectly identical call logs, which may be impossible in realworld devices.

The covert identifiers between client and server may be encrypted foradded security, with the encryption keys being unique between clients,but the covert identifiers may be non-encrypted covert data values inother embodiments. In some embodiments, key-less security between aclient and server may be involved, using only the covert data values orcovert identifiers based on such values to identify client devices.However, the security is enhanced when the client/server communicationsare encrypted. Covert data or covert identifiers may be used in manyways to operationally identify a client without the need for a pair ofencryption keys. In fact, the covert data scheme described above can beused in all message transactions without security specific messagesbeing required in a system. This means that the covert data techniquesdescribed herein can be used to enhance the authentication of clientswith and without security credentials such as X.509 certificates,encryption keys, and similar security specific keys. In one embodiment,all communications between a client and a server or between two computerdevices are enhanced by the techniques described herein in situationswhere an encryption specific key is not required. Embodiments can applyto all types of software and firmware running in a system includingapplication software, system middleware, billing software, any type ofe-commerce transaction, any type of client/server communications, andany type of messaging between a client and a server or where a clientneeds to be identified.

In one embodiment, covert security data may be used to provide key-lesssecurity in systems which do not use security or encryption forcommunications between client devices and web sites or servers, as wellas allowing for cloned client device detection. This embodiment isillustrated in the flow diagram of FIG. 7. In a first step 150, a clientdevice contacts a web site or server to register for service. Duringregistration, the client device sends an initial covert identifier tothe server that uniquely identifies the client device (step 152). Thecovert identifier in this embodiment comprises a series of covert datavalues, but may comprise a transformed version of such values in otherembodiments. The initial covert data values used in the covertidentifier can be any client device specific data, including the covertdata described herein, which is difficult to clone. When registering,the client can send somewhat difficult to clone client information asthe covert identifier, such as central processing unit (CPU) serialnumber if available, disk drive volume ID, or other hardware specificinformation. The registration process itself may create new covert datavalues at the server side or client side which is more difficult toclone, such as data from one or more registers in the CPU or computerhardware devices, the time delay in nano-seconds between a message sentand the response being received by the client, check sum or crc valuesof a portion of memory, and the like. The initial set or table of covertdata is captured and stored by the client device and server during theregistration process (step 154). At this point, the covert data isunique to the registered client device, and client-server communicationsproceed using the covert identifier based on this data to validate theclient device (step 155). In this case, the method for detecting clonedclient devices is as illustrated in FIG. 4. If the server receives acommunication which purports to be from the registered client device butdoes not have covert data values matching the initial covert data valuesstored at the server for that client device, a cloned device detectionreport is generated by the server.

Since hackers may be able to hack into the system and obtain the initialset of covert data values, or the covert identifier based on that datawhere it is transformed, new covert data is created based on operationalcharacteristics as the client device continues to run (step 156). Thenew covert data is added to the initial set of covert data values insubsequent communications between the server and client device (step158), with the new covert data values added to the previously storedcovert data values for that client device (step 160) at both the serverand client device. The new covert data may be created via timed eventsor counted events adding additional covert data created afterregistration to identify the client. Optionally, the server can createand deliver covert data to the client device at various times during themessage providing the client device with additional covert data that isunique for this client device. New covert data continues to be added asthe client device continues to run, so that there is no static set ofcovert data used for any extended period of time, making hacking andcloning much more difficult. At any stage, if the covert data receivedin a message from a purported real client device does not match thecurrent set of covert data stored for that client device at the server,a clone detection report is generated.

The method of FIG. 7 allows systems without security to create clientunique identifiers based on covert data which cannot easily be hacked.For certain applications, the covert data techniques alone may provideadequate security, or the covert data techniques may be added to systemswhere the client/server messaging is secured using best-of-breedencryptions techniques enhanced with the covert data methods describedherein, for example as described in connection with FIGS. 5 and 6 and inTable 2.

The covert data techniques described above may be used to enhancesecurity when encryption keys are also used to encrypt messages betweencomputer devices or keys are used to securely identify computers on anetwork. When a cloned client device is created, the cloned device hasthe identical keys of an authorized, authentic or real client device andcan decrypt all messages being sent between the authorized authenticreal client device and the server. However, operationally the realclient device and the cloned client device perform certain functionsdifferently over time, or have different operational counter values(number of ECM processed, time of day when 10th channel change occurred,and the like), so that the covert data generated by the real clientdevice and the cloned client device differs, as explained above.

In many cases the actual value of the covert data is not important butwhat is important is that the operational behavior of a client devicesuch as a set top box is different under normal operating conditionswhen compared to a cloned copy of the authentic client device. Thismeans that that covert data values differ from client-to-client evenwhen client devices have cloned client credentials identical to the realclient device. In some embodiments, these operational differences areused to detect covert data values or covert identifiers based on suchvalues that differ between an authentic client device and a clonedclient device, and one embodiment of such a method is explained above inconjunction with FIGS. 5 and 6 and Table 2. In addition, the covert datavalues may be “counter values” which are weighted with a scaling factorrequiring that the client device operate for a period of time before avalue changes, thus providing data values that remain fixed at a singlevalue for days, weeks, or months of operation. In one embodiment, one ormore covert data values are utilized as a covert identifier in themessaging between client device and server. In one embodiment, more thanone covert data value is used with different thresholds or triggers thatresult in the various covert data values changing at different rates.Table 4 below shows an example of three covert data values or items in amessage called “Get Key Message” and the changes in the covert dataitems over time.

The embodiment of FIGS. 5A and 5B and Table 2 used a Broadcast Key orBKEY request for sending covert data values, and the same techniquesdescribed below in Table 4 for the Get Key Message can be used on theBroadcast Key or BKEY request example or any other messages used betweena client device and server. Also note that the covert data items orvalues can originate on either the client device, or the server, or bothand that covert data values can be the results obtained by processing adata value such as by using a hash function, or seeding a random numbervalue or performing a transform on the data value used as part of thecovert data scheme.

TABLE 4 Get Key Message (GKM) and Covert Data over time GKM GKM MessageGKM Message GKM GKM GKM GKM after Message after Message Message MessageMsg Message Power after 2 Counter 1 after 1 after 9 after 2 after 3Fields on reset days trigger week days weeks weeks GKM 1 1 1 1 1 1 1Message ID Covert 0 0 0 0 0 31 31 Data Item 1 Covert 0 0 0 0 88359 8835988359 Data Item 2 Covert 0 0 7190 7190 SQR of SQR of SQR Data 7190 7190of Item 3 7190

The above example in Table 4 shows how three covert data values or items1, 2, 3 in a Get Key Message (GKM) change over time. The GKM Message IDshown in the above table as a value of ‘1’ identifies the message asbeing a Get Key Message. It is envisioned that, after each firmwarerevision, the covert identifier being sent as part of the client/servercommunications for a particular function such as a get key request (orany other event such as an e-commerce transaction or other transaction)contains different covert data items than the prior firmware release,making prior firmware hacks useless on the system. In the above example,the covert data items are different operational values generated at theclient device or server, and may be any of the possible covert dataitems or values described above, or any other unique data derived fromoperation of a client device. If the server receives a GKM message atany time which does not match the current GKM message stored for theparticular client device, it generates a cloned client device detectionreport.

In the above example, the Message ID for the Get Key Message does notneed to change and is considered a static Message ID value to indicateone of a number of message types for communications between the clientand server. However, the Message IDs can change between different clientfirmware versions, forcing would be hackers to have to reverse engineerthe new Message IDs when a client firmware update is achieved. Afirmware revision number may be contained in the message ID to allow theserver to work with different client firmware versions.

In one embodiment, the covert data items gathered for various firmwarereleases differs between the different versions. Table 5 below shows anembodiment of possible covert data fields for three different firmwarereleases. This table shows the contents of three covert data fields forthree different firmware releases named release 1.0, 1.1, and 1.2, withthe various releases occurring over a period of one year, for example.The covert identifiers in messages between client device and server, orserver and client device, or both, consist of three covert data items,with the nature of the covert data items being dependent on the currentfirmware release used. The table is read by reading down each column.The three covert data items for release 1.0 of the firmware are the 4thmessage token from the server, the scaled ECM packet count, and the timeof day for the third message of a particular type received. In release1.1, these items change to a scaled count of the total number of hoursthe client device has been running, a token received from the serverafter the 6^(th) message of a particular type with the server, and thetime of day when the 10,000^(th) message of a particular type wasreceived by the client device. In release 1.2, all three covert dataitems are again changed, with covert data item 2 changed to zero, andthe other covert data items changed to time of day when the 150^(th)message of a particular type was received, and the value of the channelnumber that the client device was tuned to at 8:37 pm on the day the newfirmware was installed.

TABLE 5 Example of covert data values in different firmware releasesCovert Data Item Value of number in covert data Value of covert dataValue of covert data message in release 1.0 in release 1.1 in release1.2 1 Token received Scaled count of the Time of day when from serverafter total number of the 150^(th) message of 4^(th) message hoursclient device a particular type was with server has been runningreceived 2 Scaled count of Token received Always set to 0 and ECMpackets from server after 6^(th) never changes received message withserver 3 Time of day when Time of day when The value of the 3^(rd)message of a the 10,000^(th) channel number that particular type messageof a the client was tuned was received particular type was to at 8:37 pmreceived

In one embodiment the covert data item or items used for any singlefirmware release can also change at predetermined times or in responseto predetermined triggers. For example, say that a certain revision ofcode is released in the month of March and loaded onto the clientdevice. For the first two months after the revision is loaded, covertdata item 2 is the time of day the firmware was updated. Then, after twomore months, covert data item 2 changes to a data value provided by theserver. Then, after four months of operation of this firmware release,the data item 2 changes to the register value contained in a chip on theclient device at the four month anniversary of loading the revision. Inthis embodiment, the value of a covert data item changed three timesduring the first four months of operation, so that hackers have moredifficulty in successfully running clones of the client device. When thevalue of pre-stored covert data items change at a particular epoch, theserver is aware of the epoch and adjusts its database appropriately. Forexample, say that after 90 days of operation the client library isdesigned to generate an entirely new covert data table or matrix, thenthe server is aware that after 90 days of use the client is reportingnew covert data. In fact, even synchronizing the clones to flush theirold covert data tables and refresh to new data at the same time presentshackers with logistical problems, especially when the hacker may not beexpecting the covert data values to be changed.

There are many different possible covert data items and covert datatriggers generated by the client device operation, the servercommunicating with the client device, or both, which may be used togenerate client identifiers added to messages in the embodimentsdescribed above. One or more covert data items may be a token or a timeprovided by the server to the client device as part of the messageresponse and the server provided data item is returned back to theserver by the client device at a later time (maybe at the next requestby a client device), for example as described above in connection withFIGS. 5 and 6 and Table 2. This allows the server to generate tokensused as covert data to identify clones. Covert data can also be a countof the number of messages processed by a client device or the number ofmessages written to a message log or message queue by the client device,or the value of the 10th API call to a client API function, or othersimilar event that would normally vary between client devices even withidentical credentials.

In many cases the client device may not know or even care what themeaning of the covert data is, because it is information used on theserver side to detect clones, or it was information provided by theserver to detect clones. In one embodiment, some covert data values aregenerated based on one-time events such as what channel was the clientdevice tuned to after a particular time period of operation of a newclient device, e.g. 23:49:33 (hours:minute:seconds) of operation. Othercovert data values may be generated using network or system operationalvalues such as cable modem ranging parameters, DHCP lease times, and thelike. Still other covert data values may be supplied by the server.Other covert data values may result from the messaging between a clientdevice and a server, or other parameters normally found in theenvironment for the product. For examples, PCs can have different covertdata values than wireless phones.

A security system using covert data generated by client deviceoperational events as described in the above embodiments may also bedesigned to include a subscriber entitlement renewal process, eitherwhen cloned or pirated client devices are detected by the system orsuspected for other reasons, or at predetermined intervals regardless ofsuspected cloned client devices. FIG. 8 illustrates an embodiment of therenewal process for a two way network or a one way network with a returnchannel. Any form of persistent or non-persistent (sporadicallyavailable) return channel such as an occasional dial-up modem connectionor a return channel formed when a cellular phone is connected to aclient device such as a STB can be used for renewal as in FIG. 8. Asimilar process may also be used on a one way network without a returnchannel, and one embodiment of such a process is illustrated in the flowdiagram of FIG. 9.

The process of FIG. 8 may be used in a renewal process in connectionwith two way networks or a one way network with a return channel. Asillustrated in FIG. 8, a request for covert identifier is sent by aserver over a network to individual clients (on 2 way networks) or allclient devices (on one way network). Server sends a Renewal Message toClient (181). Assuming that a return channel is available (182), theclient devices are programmed to respond by sending the current covertidentifier back to the server (step 184). If a return channel is notavailable (i.e. the client device is operating on a one way network withno return channel), the procedure continues as illustrated in FIG. 9 anddescribed in more detail below.

The covert data identifier sent back in step 184 for networks having areturn channel is based on the covert data collected by a particularclient device, which in turn is related to operational events at thatclient device. Since the covert identifier has just been updated in eachclient device, hackers have to re-start their hacking to find the covertidentifier of the real client device immediately after receiving theupdate code in step 179, and attempt to duplicate that covert identifierin any clone device. Such hacking attempts are unlikely to be successfulin time for the covert identifier to be duplicated before the responsecontaining the covert identifier for each client device is sent backautomatically from each client device in step 184. In one embodiment,the covert data identifier is an eight digit code generated fromcollected covert data values, and contains no subscriber relatedbehavioral information or privacy related information. However, othercodes based on covert data values may be generated in alternativeembodiments. The server then determines whether more than one responsehas been received with the same client identifier but different covertdata (step 185). If only one response is received, a renewal unlock codebased on the covert identifier received from the client device iscreated by the server (step 186) and transmitted to the client device(step 188). If only one response is received, there are most likely noclones of the real client device on the network, and the real clientdevice unlocks the renewal code and is renewed for service. However, ifthe real client device did not send a response for some reason, orcloned client devices did not send a response, more than one clientdevice may still receive the renewal unlock code, since this code isbroadcast to all client devices operating under the same clientidentifier or credentials. Only the client device with the same covertdata identifier is able to unlock the renewal code and be renewed forservices through the network. Any other client devices using the sameclient identifier are not be able to unlock the renewal code, and areblocked from receiving services. If the renewed client device isactually a clone, the real subscriber is blocked and calls the serviceprovider to complain. In this case, the cloned device is blocked and theservice with the real subscriber's client device is renewed. An optionalstep not shown in FIG. 8 and before step 181 would be to send a covertidentifier update message to the client to have the client at thatmoment obtain yet another new covert data value and add it to the covertdata table being returned in step 184. Each client device receiving themessage then updates the covert identifier based on current operatingcharacteristics of the particular device for the particular piece ofcovert data being captured.

If more than one client device response with a covert identifier hasbeen received at step 185, the real client device is identified (step189). Identification of the real client device at step 189 may comprisea network user authentication method as described in co-pendingapplication Ser. No. 11/489,779 filed on Jul. 20, 2006, the contents ofwhich are incorporated herein by reference. In this method, authorizedsubscribers are associated with the location of physical connections tothe client device, and the network is probed in step 189 to determinewhich client device is at the correct physical network location for theauthorized subscriber. When the correct or real client device islocated, a renewal unlock code based on the covert data received fromthat client device is created in step 190, and is broadcast over thenetwork in step 192 to all client devices having the same client onone-way networks and delivered uniquely to clients on two-way networks.Services are blocked to all such client devices, and only the realclient device can unlock the renewal code and renew services.

If the service provider does not have authentication procedures based onphysical location or physical connection identifiers for real clientdevices, the real client device may be located by other techniques, suchas having a service operator call the subscriber and having thesubscriber look up the covert identifier on the real client device andprovide that identifier to the service provider in an SMS message orover the phone.

FIG. 9 illustrates steps in a periodic renewal process which may be usedin connection with a covert data security system for client devices onone way networks having no return channel. This renewal process uses thesame initial steps 179, 180 and 181 as illustrated in FIG. 8. However,in response to the service code renewal message, the central processorat the client device is programmed to display a service code or renewalmessage on the screen of the client device (step 193). This messageincludes the client identifier and the current covert identifierretrieved from the covert data storage module 29. The client identifierfor the client device is identical for real client devices and clonedclient devices, but the current covert identifier stored at the clientdevice is different for each client device. The service code messageincludes a request that the user sends the two IDs to a telephone numberdisplayed on the screen, which may be an 800 number for the serviceprovider.

In step 194, the user of the client device provides the clientidentifier and covert data ID to the service provider as an SMS messageto the telephone number on the screen, or alternatively via a voicetelephone call to an operator at the service provider. At this stage,the service provider may be able to determine whether the sender of themessage or the caller is the authorized subscriber, based on personalinformation or security information stored at the server, such as thetelephone number of the authorized subscriber. If it is determined thatthe caller is the authorized subscriber, the server or service providergenerates a renewal unlock code based on the unique covert data IDreceived from the user in step 195, and sends or broadcasts the renewalunlock code to all client devices on the network with the same clientidentifier (step 196). If the client device receiving the code is ableto correctly process the unlock code (step 197), service is renewed forthat device (198). If a client device receiving the code is unable tocorrectly process the unlock code, because the covert data stored atthat client device does not match the covert data in the unlock code,service to that client device is blocked (step 199). If the system hasincorrectly determined that a caller or sender of the requested messageis the authorized subscriber, and the user is actually using a cloneddevice, so that the real client device is unable to process the renewalunlock code, the authorized user calls the service provider becausetheir service has been blocked. A further renewal unlock code can thenbe generated based on the covert data at the real client device andbroadcast to client devices so that the previously renewed device isblocked and the real client device is renewed for service.

The renewal processes described above in connection with FIGS. 8 and 9may occur at predetermined intervals or when presence of one or morecloned client devices on a network is suspected, or both. The renewalprocess as described in FIGS. 8 and 9 can use any part of the covertdata tables or pieces of the covert data tables to generate clientdevice specific unlock codes whereby cloned clients with differentcovert data values are not be able to generate the appropriate keys todecrypt the unlock code. An example of such a client specific keymanagement scheme is Diffie Hellman. Other types of key exchangemechanisms can be used. Using Diffie Hellman for example, covert data(any or all) is used as part of the seeding mechanism used to generatethe client side unique key or part of the data used to provide serverside compatible keys such that cloned clients with different covert datavalues are not able to generate the same unique keypair (Diffie Hellmankeypair) between other cloned devices. Another way the renewal processcan be achieved is by having the server use the covert data received fora client in a known way to seed or generate shared pairing keys inalgorithms such as Diffie Hellman, and in essence, generating a uniquekey pair that can only be recreated by the client containing theappropriate covert data. Another optional method of performing clientdevice renewal is to use part of the covert data asencryption/decryption key data because each client has unique covertdata and the unique covert data is known to the server. Pieces or all ofthe covert data or hashed or transformed versions of the covert data canbe applied to keys or seed data or factors used to generateencryption/decryption key data or used in generating shared keys withalgorithms such as Diffie Hellman. It is also anticipated that thecovert data can be used to scramble or transform key seed or key factordata being sent between the client and server, or server and clientduring the renewal process. For example, the covert data can be hashedby the client and then used as a key when encrypting data being sent tothe server. And, because the server knows the covert data, the servercan perform the same hash to generate the decryption key.

Again, using Diffie Hellman as an example, a covert data base KeyExchange can work as follows:

-   -   1. Alice chooses a random large integer X and sends Bob X=(ĝx        mod n ) encrypted with Covert Data    -   2. Bob chooses a random large integer Y and sends Alice Y=(ĝy        mod n) encrypted with Covert Data    -   3. Alice decrypts Bob's encrypted Y and computes K=Ŷx mod n    -   4. Bob decrypts Alice's encrypted X and computes K′=X̂y mod n        Following Diffie Hellman both K and K′ are equal and the covert        data was used as an encryption key for transferring data. Covert        data can be used in more ways than only encryption key data and        can be used as seed data for the random large integer        calculations or hash applied to data and values used in        algorithm calculations.

In the above embodiments, a unique covert identifier is generated basedon operational events occurring during operation or use of a clientdevice, based on how the client or subscriber uses the client device.These operational events are different between real client devices andcloned client devices because cloned client devices are operated bytheir users differently from users of real client devices or othercloned client devices. Such operations are extremely difficult toduplicate. The covert identifier may be used to detect cloned clientdevices and also in a periodic renewal process which may eliminateservice to cloned client devices.

Those of skill will appreciate that the various illustrative logicalblocks, modules, circuits, and algorithm steps described in connectionwith the embodiments disclosed herein can often be implemented aselectronic hardware, computer software, or combinations of both. Toclearly illustrate this interchangeability of hardware and software,various illustrative components, blocks, modules, circuits, and stepshave been described above generally in terms of their functionality.Whether such functionality is implemented as hardware or softwaredepends upon the particular application and design constraints imposedon the overall system. Skilled persons can implement the describedfunctionality in varying ways for each particular application, but suchimplementation decisions should not be interpreted as causing adeparture from the scope of the invention. In addition, the grouping offunctions within a module, block or step is for ease of description.Specific functions or steps can be moved from one module or blockwithout departing from the invention.

The various illustrative logical blocks and modules described inconnection with the embodiments disclosed herein can be implemented orperformed with a general purpose processor, a digital signal processor(DSP), an application specific integrated circuit (ASIC), a fieldprogrammable gate array (FPGA) or other programmable logic device,discrete gate or transistor logic, discrete hardware components, or anycombination thereof designed to perform the functions described herein.A general-purpose processor can be a microprocessor, but in thealternative, the processor can be any processor, controller,microcontroller, or state machine. A processor can also be implementedas a combination of computing devices, for example, a combination of aDSP and a microprocessor, a plurality of microprocessors, one or moremicroprocessors in conjunction with a DSP core, or any other suchconfiguration.

The steps of a method or algorithm described in connection with theembodiments disclosed herein can be embodied directly in hardware, in asoftware module executed by a processor, or in a combination of the two.A software module can reside in RAM memory, flash memory, ROM memory,EPROM memory, EEPROM memory, registers, hard disk, a removable disk, aCD-ROM, or any other form of storage medium. An exemplary storage mediumcan be coupled to the processor such that the processor can readinformation from, and write information to, the storage medium. In thealternative, the storage medium can be integral to the processor. Theprocessor and the storage medium can reside in an ASIC.

Various embodiments may also be implemented primarily in hardware using,for example, components such as application specific integrated circuits(“ASICs”), or field programmable gate arrays (“FPGAs”). Implementationof a hardware state machine capable of performing the functionsdescribed herein will also be apparent to those skilled in the relevantart. Various embodiments may also be implemented using a combination ofboth hardware and software.

The above description of the disclosed embodiments is provided to enableany person skilled in the art to make or use the invention. Variousmodifications to these embodiments will be readily apparent to thoseskilled in the art, and the generic principles described herein can beapplied to other embodiments without departing from the spirit or scopeof the invention. Thus, it is to be understood that the description anddrawings presented herein represent a presently preferred embodiment ofthe invention and are therefore representative of the subject matterwhich is broadly contemplated by the present invention. It is furtherunderstood that the scope of the present invention fully encompassesother embodiments that may become obvious to those skilled in the artand that the scope of the present invention is accordingly limited bynothing other than the appended claims.

1. A method of detecting cloned client devices communicating over anetwork, comprising: storing at a server at least one covert identifierfor a client device having credentials registered at a server; receivinga message from a client device at the server, the message containing acovert identifier derived from at least one operational event of theclient device; determining whether the covert identifier received in themessage matches a covert identifier for the client device having thesame credentials stored at the server; and reporting detection of aclone of a real client device if at least part of the covert identifierin the message does not match the covert identifier stored for theclient device at the server.
 2. The method of claim 1, wherein thecovert identifier comprises selected covert data values generated byoperational events at a client device, and detection of a clone of areal client device is reported if covert data values in a covertidentifier received from a client device do not match any covert datavalues in a covert identifier stored at the server.
 3. The method ofclaim 1, wherein the covert identifier comprises a code based onselected covert data values generated by different operational events ata client device.
 4. The method of claim 1, wherein the covert identifieris at least partially based on at least one token provided by the serverto the client device.
 5. The method of claim 1, wherein the covertidentifier is based on covert data values generated by the clientdevice.
 6. The method of claim 1, wherein the covert identifier is basedon covert data generated by the server and provided by the server in amessage to the client device.
 7. The method of claim 1, wherein thecovert identifier is based on covert data values generated by the clientdevice and the server.
 8. The method of claim 1, further comprisingupdating the covert identifier periodically at a client device based onpredetermined event triggers and providing the updated covert identifierin a message to the server.
 9. The method of claim 8, wherein at leastone event trigger comprises installation of updated firmware on a clientdevice.
 10. The method of claim 8, wherein at least one event triggercomprises receipt of a predetermined number of a particular type ofmessage from the server.
 11. The method of claim 8, wherein at least oneevent trigger comprises sending a predetermined number of a particulartype of message from the client device.
 12. The method of claim 8,wherein at least one event trigger comprises a predetermined number ofchannel changes at the client device.
 13. The method of claim 2, whereinthe step of storing at least one covert identifier at the servercomprises storing a first covert data value at the server on receipt ofa predetermined message from a client device, and storing an updated,second covert data value when a subsequent predetermined message isreceived from a client device having the same credentials, and the stepof determining whether a covert identifier received in a subsequentmessage from a client device matches a previously stored covertidentifier comprises comparing a covert data value in the message withthe first and second covert data values stored at the server, wherebydetection of a cloned client device using the same credentials isreported if the covert data value in the subsequent message does notmatch at least one of the first and second covert data values.
 14. Themethod of claim 13, wherein the covert data values are based on the timeof sending the predetermined messages.
 15. The method of claim 13,wherein the covert data values stored at the server are based on covertdata values received in messages from at least one client device. 16.The method of claim 2, further comprising periodically changing at leastone covert data value to a different covert data value based on adifferent operational event at a client device.
 17. A method of renewingsubscriber client devices on a network, comprising: creating a covertidentifier at a client device based on operational events at the clientdevice; receiving a service renewal message at the client device;providing the covert identifier to the service provider in response tothe service renewal message; receiving a renewal code message at theclient device over the network, the renewal code message containing arenewal unlock code based on the covert identifier; and processing therenewal unlock code using the covert identifier to receive continuedservices from the service provider.
 18. The method of claim 17, furthercomprising receiving an update covert identifier message at the clientdevice prior to the service renewal message, and updating the covertidentifier at the client device before providing the updated covertidentifier to the service provider.
 19. The method of claim 17, whereinthe covert identifier comprises a code based on selected covert datavalues generated by different operational events at a client device. 20.The method of claim 17, wherein the step of providing the covertidentifier to the service provider comprises sending the covertidentifier in a message over the network to a server associated with theservice provider.
 21. A system for detecting cloned client devices on anetwork, comprising: a server having a communication module whichcommunicates with client devices over a network; a data storage moduleassociated with the server which stores a client identifier associatedwith at least one real client device registered for service with theserver and at least one covert identifier received from a client devicehaving the same client identifier; and a clone detection moduleassociated with the server and data storage module which compares atleast one covert identifier in a message received from a client devicewith the stored covert identifier associated with the same clientidentifier, and which creates a clone detection report if the covertidentifiers do not match.
 22. The system of claim 21, further comprisinga plurality of client devices communicating with the server over thenetwork.
 23. The system of claim 22 wherein the client devices are smartcards.
 24. The system of claim 22, wherein at least some of the clientdevices include smart cards.
 25. The system of claim 22, wherein atleast some of the client devices are set top boxes.
 26. The system ofclaim 22, wherein at least some of the client devices are mobilecommunication devices.
 27. The system of claim 22, wherein at least someof the client devices are personal computers.
 28. The system of claim22, wherein each client device has a covert identifier generating modulewhich generates a covert identifier based on at least one covert datavalue corresponding to an operational event at the client device, acovert data storage module which stores covert data values, and amessage formatting module which embeds the covert identifier in at leastone message sent to the server over the network.
 29. The system of claim28, wherein the covert identifier comprises at least one actual covertdata value.
 30. The system of claim 28, wherein the covert identifiercomprises a transformed version of at least one covert data value. 31.The system of claim 28, wherein the covert identifier comprises aplurality of covert data values corresponding to different operationalevents at the client device.
 32. The system of claim 28, wherein thecovert identifier comprises a transformed version of a plurality ofcovert data values corresponding to different operational events at theclient device.
 33. A client device for communicating over a network,comprising: a communication module which communicates with at least oneserver over a network; a covert identifier generating module whichcreates at least one covert identifier based on at least one covert datavalue of an operational event at the client device; and a data storagemodule associated with the covert data generating module which storesthe covert data value.
 34. The client device of claim 33, furthercomprising a message formatting module associated with the communicationmodule and data storage module which creates at least one messagecontaining the covert identifier for communication to the server. 35.The client device of claim 33, wherein the data storage module stores acovert data table of different covert data values of differentoperational events and the covert identifier is based on the covert datatable.
 36. The client device of claim 35, wherein the covert identifiercomprises at least some of the covert data values in the covert datatable.
 37. The client device of claim 35, wherein the covert identifieris a transformation of at least some of the covert data values.
 38. Theclient device of claim 35, further comprising a covert data updatemodule configured to update the table of covert data values with atleast some new covert data values in response to at least onepredetermined covert data trigger.
 39. The client device of claim 33,wherein the covert identifier generating module is configured togenerate an updated client identifier based on new covert data values inresponse to a command.
 40. The client device of claim 39, wherein thecommand comprises an update command received in a network message. 41.The client device of claim 39, wherein the command comprises a covertdata trigger.
 42. The client device of claim 39, further comprising arenewal module which responds to a renewal message received from aserver of over the network by sending a current covert identifier to theserver.
 43. The client device of claim 33, comprising a smart cardhaving an integral processor containing the communication module, covertidentifier generating module, and data storage module.
 44. The clientdevice of claim 33, wherein the device is selected from the groupconsisting of set top boxes, personal computers, personal digitalassistants, portable communication devices, media playing devices, andsmart cards.
 45. The client device of claim 33, wherein the clientdevice is a silicon chip including a covert identifier generating moduleand data storage module.
 46. The method of claim 1, wherein the covertidentifier is at least partially based on at least one encryption keyprovided by the server to the client device.
 47. The method of claim 1,wherein the covert identifier is at least partially based on at leastone encryption key provided by the server to the client device andwherein said client uses the said server provided encryption key toencryption communications between said client and said server.
 48. Themethod of claim 1, further comprising adding additional covertidentifiers periodically at a client device based on predetermined eventtriggers wherein the said additional covert identifiers adds to theprevious covert identifiers.
 49. The method of claim 1, wherein thecovert identifier is based on the time of day an event occurred in theclient device.